The present invention relates to a service on IP (Internet Protocol), in particular to IP telephony called “Voice over IP”.
IP telephony advantageously allows, on the one hand, a reduction of the cost of telephonic communications in comparison with conventional telephony and, on the other hand, the coupling of telephony with the functions and services of data processing and of IP networks.
A telephony service is a real time service which requires a relatively high level of availability, robustness and resistance to failure. In the context of conventional telephony (STN for ‘Switched Telephone Network’), based on circuit switching, this level of robustness and availability is obtained by the use of methods which are not applicable to IP telephony, which is not based on circuit switching.
An IP network offering a telephony service conventionally comprises a service platform, as well as equipment for accessing the service, or POPs (Points Of Presence), which are in charge of managing the access of user client terminals to the service in question.
In a standard fashion, these POPs are associated with Border Session Controller (BSC) equipment (also known as Session Border Controller (SBC) equipment), whose principal functions have been identified in the document ‘Requirements from Session Initiation Protocol Session Border Control Deployments’, by Camarillo et al., draft-ietf-sipping-sbc-funcs, November 2006. These SBCs are situated between the client terminals and the platforms of the IP telephony service. An SBC is in general situated in a POP for access to the IP network (without this however being a necessary condition for the functioning of the telephony service) and represents, for a given client terminal, a unique point of entry to the telephony service. Such management of access to a service makes it possible to mask the service platform and, more generally, the network architecture used by an operator, from the client terminals. It is then possible to guarantee service impregnability.
SBCs correspond to a point of passage both for the signalling flows, aimed at establishing a communication, and for the media flows which pass between the client terminals. The signalling flows can be for the establishment of a communication, for example on the basis of protocols such as SIP (Session Initiation Protocol), or H.323, such as defined by the ITU-T (International Telecommunication Union Telecommunication Standardization Section), or IAX (Inter-Asterisk eXchange Version 2) such as defined in the document draft-guy-iax-02, Work In Progress, October 2006 by Spencer, Shumard, Capouch and Guy. As for the media flows, these can be exchanged between client terminals according to protocols of the RTP (Real-Time Transport Protocol) type, or of the IAX type for example.
An SBC therefore receives, on the one hand, signalling messages from the service platform, or from the client terminals respectively. Then, after processing these messages, the SBC relays them to the final client terminals, or respectively to the service platform.
Then, when a media flow is exchanged from a first client terminal to a second client terminal used by a client of the service, which are associated with a first and a second SBC respectively, this media flow is received at the first SBC, then relayed to the second SBC, the latter then being in charge of transmitting this media flow to the second client terminal. By proceeding thus, the client terminals cannot communicate directly with each other, the impregnability of service being thus being guaranteed.
It can also be noted that the SBCs can also provide other functions such as a filtering function or an address translation function for services based on the IPv4 (version 4) protocol.
When an SBC can no longer communicate with the platform, the service offered to the clients of client terminals that it manages is terminated. In order to increase the resistance to failures in such a network, and to transport, in a robust and efficient manner, the signalling messages allowing the establishment of the communications as well as the transport of the media flows between the client terminals, it is possible to provide a redundancy of the elements of the service platform in the form of backup elements, such that it is possible to substitute a backup element for a defective element of the service platform. Such architecture requires that such a backup element has a configuration and a behaviour that are identical to those of the defective element for which it must be substituted.
However, the provision of such backup equipment for the service platform has many drawbacks. Firstly, the duplication of these elements is costly both at the level of the infrastructure to be set up and at the level of the actual management of the redundancy.
Moreover, such redundancy does not make it possible to overcome, in all circumstances, the consequences of a failure relating to the links between the service platform and the SBCs.